Homebrew Is it possible to make a Download Play exploit?

[Mrrraou]

you would create a security flaw

Um...

 

[TuxSH]

Um...

Let's ask Nintendo!

 

[GalladeGuy]

Let's ask Nintendo!

@ Nintendo No, I wasn't actually trying to notify anyone.

 

[JustPingo]

Just had an idea about downgrading... We can't downgrade (unless we delete the old firmware) because of the system check, right ? So what about customizing a vulnerable firmware (like 9.2) changing its sysver to 10.4 or whatever, it should bypass the check and thus install the firmware, because it is technically newer than the current console firmware

So we would have a 9.2 fimrware exploits with a 10.4 sysver...

If you have that kind of access, kernel11hax is really not that far anyway. Trust me.
So you can delete those checks whenever you want.

 

[The9thBit]

There haven't been any download play exploits to date that I know of, and I'm not expecting to be able to distribute a hacked download play child any time soon. The code is checked before it runs, so we can't get away with unsigned download play. I'll bet that we could do the reverse though; connecting a hacked client that would trigger a buffer overflow exploit (or something similar) on the host system. From there a more permanent save file exploit could be saved to the game, sort of like how Ninjhax is able to write itself to the save file so the QR isn't needed.

 

[gudenau]

TL;DR

The method that the OP is talking about is not going to happen. But there is a chance you could cause some sort of buffer overflow by messing with compressed data or sending to much data in something. Then you would need to get lucky and have it overwrite something that you can use to get code ROP from the data you send. From there if you have some space it is "easy" to get ASM from the ROP chain.

 

[froggestspirit]

hmmm, if you upgrade through dlp, which system does the check?

 

[dark_samus3]

hmmm, if you upgrade through dlp, which system does the check?

The client 3ds does the check there, since the host 3ds doesn't (and shouldn't) have access to the other console's security

 

[froggestspirit]

The client 3ds does the check there, since the host 3ds doesn't (and shouldn't) have access to the other console's security

oh, well then just hack the dlp on the host so the check always passes, and sends older FW to the client
EDIT: got ahead of myself
is there a basic routine of how the check happens?
is the host responsible for the location of the fw it sends?

 

[dark_samus3]

oh, well then just hack the dlp on the host so the check always passes, and sends older FW to the client
EDIT: got ahead of myself
is there a basic routine of how the check happens?
is the host responsible for the location of the fw it sends?

Eh what? I just said the client checks... And I guess vice versa too... Basically each system does its own check on any update CIAs that are passed to it

 

[PaiiNSteven]

Heres another idea (which is probably pre 9.2) - Nintendo DS Connections. From the wifi area in settings.

 

[orly3]

Here's something that 'might' be possible:
Apparently dlp can send custom romfs files to an unhacked client, if this is true, it opens a whole new world of homebrew entrypoints!
Some examples that could be possible:
Rename an MK7 track name to cause a buffer overflow (if there aren't any protections against it, 'toad circuit' could become 'toad circuit0x7c4/rop'), resulting in rop access and from there, allow access to homebrew.
Or you could cause an overflow in the character names (mario becomes mario0x2c/rop)
It doesn't have to be mario kart (I'm not even sure if MK7 accesses the sd), you could literally edit any text/value you wanted in nearly any dlp game and send it to another console.

I haven't tested any of the above yet, I'm just saying there could be some unexplored attack vectors in the dlp protocol.

edit: MK7 does access the sdcard for ghost data etc...

 

[froggestspirit]

Here's something that 'might' be possible:
Apparently dlp can send custom romfs files to an unhacked client, if this is true, it opens a whole new world of homebrew entrypoints!
Some examples that could be possible:
Rename an MK7 track name to cause a buffer overflow (if there aren't any protections against it, 'toad circuit' could become 'toad circuit0x7c4/rop'), resulting in rop access and from there, allow access to homebrew.
Or you could cause an overflow in the character names (mario becomes mario0x2c/rop)
It doesn't have to be mario kart (I'm not even sure if MK7 accesses the sd), you could literally edit any text/value you wanted in nearly any dlp game and send it to another console.

I haven't tested any of the above yet, I'm just saying there could be some unexplored attack vectors in the dlp protocol.

edit: MK7 does access the sdcard for ghost data etc...

Not sure if that too useful, seen as how any custom romFS can already be done with hans and not needing dlp

 

[orly3]

Not sure if that too useful, seen as how any custom romFS can already be done with hans and not needing dlp

If it was possible, it would be able to transfer the exploit to another system, allowing a console to share hax.
This wouldn't be convenient if you had to do it every time you wanted to load homebrew, but it would be useful for installing secondary hax on an internal app (like ironhax) on a 10.3 console without any gamecards.

 

[froggestspirit]

In a sense, yes. But nintendo would be fools to not fix that if it's even true

 

[NodePoint]

One should note that the download play application allows you to access two different modes. For 3DS or NDS games.
If there's a vulnerability in the firmware that's used in the NDS mode (download play) then...

 

[Mrrraou]

One should note that the download play application allows you to access two different modes. For 3DS or NDS games.
If there's a vulnerability in the firmware that's used in the NDS mode (download play) then...

No. The NDS one has RSA checks (it had from the beginning). But maybe that a vuln in a game that is sent could be found. But it would be pretty useless anyway.