Homebrew Homebrew Development

[gamesquest1]

there is a huge gain in updating to 6.3, as most likely, a kernel exploit will be found (not sure if one will ever be released) for it sometime later on. the huge gain is the 6.X keys. that would fix youtube and the 6.x saves. that would allow pokemon carts to be used between updated consoles and the 6.3 one without wiping the save every time.

i believe the youtube app uses 7.x keys, so it wouldn't really solve that...unless it does turn out to work with 7.x
it would solve the 6.x save issues though, but once again only for people who haven't already started their games using the 4.x keys in emunand....plus it would likely make everyone saves incompatible...unless its patched to detect the save keys used and switch as appropriate

 

[VMM]

I wouldn't be assuming this, smealum wants to release only user-mode stuff,
so there is a big chance he releases his exploit without kernel access.

Maybe, but for now there is no point in updating from 4.5 to 6.3.
If someone release a way to acccess kernel trough SSSpwn, then there is a reason to update,
but for now, it doesn't even make sense, since 4.5 will probably be able to run SSSpwn too.

 

[Thorhian]

Well well well, I have a 6.3 3DS Time to get cracking with my studies and have some fun with this when it comes out.

 

[bobmcjr]

That other ROP launcher works great. Also, does there happen to be a RAM dumper that dumps more than the first 3MB of RAM?

 

[windwakr]

That other ROP launcher works great. Also, does there happen to be a RAM dumper that dumps more than the first 3MB of RAM?

http://gbatemp.net/threads/homebrew-development.360646/page-19#post-4908000

The SD in your 3DS has to be an SDHC card for that dumper to work.

 

[KnightMario]

I'm using a SDHC card 16 gb class 10, tried both gateway and rop and it didn't work.

 

[misterb98]

Okay, this is a noob question. What would happen if you were to run the exploit while in GW mode? I know you can't run a ds cart while in the mode, but couldn't you inject NAND with the exploit already installed into the emuNAND? If that could be done, would RAM dumping from ROMs be possible?

Exploitception

I'm under the impression that the only reason some games don't have a lot of ram dumps is because of this. Thoughts?

 

[gamesquest1]

basically the ram dumper seems to crash if you have been playing a game before hand, so its kinda annoying to keep repeating a 30 min dump process when it just crashes at the last minute......that's all that ever happened for me anyway, although other users seem to say it works fine for them, I tried a different SD, reformatting the SD etc but every time i played mario kart then dumped it crashed just at the end and gave nothing in the dump

as for running the exploit whilst inside gateway mode.....that just results in a black screen....im assuming they just conflict

 

[windwakr]

Okay, this is a noob question. What would happen if you were to run the exploit while in GW mode? I know you can't run a ds cart while in the mode, but couldn't you inject NAND with the exploit already installed into the emuNAND? If that could be done, would RAM dumping from ROMs be possible?

Exploitception

I'm under the impression that the only reason some games don't have a lot of ram dumps is because of this. Thoughts?

Yeah, it works. I've ran a game with my GW, then swapped launcher.dats on the SD and dumped the RAM.

But it's not that great of a way of getting stuff from a game. Better to just wait for someone to release some sort of ROM decryptor.

 

[pedro702]

well im also here for emulators xD gbc and gba xD

 

[Cjuub]

I have some questions, I hope someone can clear this up for me:

Right now there is no public way to run homebrew with kernel privileges, right? Only a select few people figured this out and have not leaked/released anything?
The python-tools at github has the tools (3dsploit.py) to generate a ROP-chain that executes custom code, supposedly WITH kernel privileges according to this post: http://gbatemp.net/threads/so-how-long-do-you-think-gateway-will-last.359699/page-3#post-4873326

However, as stated in that post, the payload is missing. Is it this specific gateway payload that is not publicly available and stopping us from running homebrew with kernel privileges?

Just want to clear that up.

 

[Slashmolder]

That is correct. No one has publicly posted exactly how to run code in privileged mode.
Those python tools enable you to run code in user mode on the arm9 processor. From there it's not too difficult to switch to privileged mode if you know what you're doing.

The method is in Gateway's arm9 payload but you could also probably find it yourself by looking at the arm9 kernel which was posted in this thread.

 

[Kane49]

That is correct. No one has publicly posted exactly how to run code in privileged mode.
Those python tools enable you to run code in user mode on the arm9 processor. From there it's not too difficult to switch to privileged mode if you know what you're doing.

The method is in Gateway's arm9 payload but you could also probably find it yourself by looking at the arm9 kernel which was posted in this thread.

What ? i posted the exact process with code samples like a month ago

 

[Slashmolder]

Oh that's right Kane49's stuff had the method in it. I never did look at it since his dropbox link got pulled.

 

[Cjuub]

What ? i posted the exact process with code samples like a month ago

Are you referring to this? http://gbatemp.net/threads/homebrew-development.360646/page-41#post-4928928
Anyway, looking through your post history it seems like you have posted a lot of interesting information here, thank you for that! I will read through them later.

So basically the answer to my question seems to be that the information to run in privileged mode is "kinda" public if you know what you are doing (we'll see if I do... ).

 

[Cjuub]

Okay, I followed the ROP chain in the 1.0 gateway launcher to a point where it's supposed to be feeding the payload and return to 0x080C3EE0. As it calls the exact same functions specified in 3dsploit.py it was just a matter of placing breakpoints at each one and nop the SVC-calls which QEMU obviously can't handle. BUUUUT...

The "payload" is just garbage... Is the ACTUAL payload also encrypted, and decrypted using hardware somewhere along the ROP chain? Or am I missing something?

Just when I thought I had it...

 

[windwakr]

Okay, I followed the ROP chain in the 1.0 gateway launcher to a point where it's supposed to be feeding the payload and return to 0x080C3EE0. As it calls the exact same functions specified in 3dsploit.py it was just a matter of placing breakpoints at each one and nop the SVC-calls which QEMU obviously can't handle. BUUUUT...

The "payload" is just garbage... Is the ACTUAL payload also encrypted, and decrypted using hardware somewhere along the ROP chain? Or am I missing something?

Just when I thought I had it...

Did you miss the final bit of the ROP chain(located at 0x002B3924)? It's decrypted with a call to EncryptDecryptAes. That last bit does the final decryption of the first arm9 payload.*

The arm9 payload starts with "0x05, 0x00, 0x00, 0xEA, 0xD0, 0x61, 0x00, 0x00".



EDIT:
*Or something like that, I've already forgotten what that last bit of the ROP chain does. But anyways, you need to use an actual 3DS to do the decryption.

 

[Cjuub]

Did you miss the final bit of the ROP chain(located at 0x002B3924)? It's decrypted with a call to EncryptDecryptAes. That last bit does the final decryption of the first arm9 payload.*

The arm9 payload starts with "0x05, 0x00, 0x00, 0xEA, 0xD0, 0x61, 0x00, 0x00".



EDIT:
*Or something like that, I've already forgotten what that last bit of the ROP chain does. But anyways, you need to use an actual 3DS to do the decryption.

Thank you! You were spot on.

EDIT:
And now I decrypted the rest:

Was a little tricky to figure out where to inject the RAM dumper, but got it after a few guesses.

 

[Bug_Checker_]

Thank you! You were spot on.

EDIT:
And now I decrypted the rest:

Was a little tricky to figure out where to inject the RAM dumper, but got it after a few guesses.

So (I must have missed it) What the 1st 4 bytes are? 0x100090F0
The next 4 bytes duplicated 3 times are nop (s) 0xE1A00000
And the last 4 byte set are 0x080C3EE0

Is this correct, and the ramdumper went where?

 

[williamcesar2]

Thank you! You were spot on.

EDIT:
And now I decrypted the rest:

Was a little tricky to figure out where to inject the RAM dumper, but got it after a few guesses.

what does that mean exactly ?