Homebrew Is it possible to make a Download Play exploit?

  • Thread starter Thread starter Stalls
  • Start date Start date
  • Views Views 12,430
  • Replies Replies 96
@dark_samus3 let me ask you this. Again with modified romfs, what about reproducing an exploit (system flaw) similar to those already used for kernel and sending that through downloadplay? Instead of looking through games and software for a security flaw, we could make one, right?

Might be possible, maybe even using Yellows8's homebrew menu CIA, just figure out how to send that over dlplay which might work
 
  • Like
Reactions: WeedZ
Might be possible, maybe even using Yellows8's homebrew menu CIA, just figure out how to send that over dlplay which might work

CIA files need to be signed with keys we won't ever have (and their titleID need to match the host game too).
 
CIA files need to be signed with keys we won't ever have (and their titleID need to match the host game too).
Not if you're using a 3ds with signatures patched already ;) yes the title ID needs to match but we can just spoof that
 
CIA files need to be signed with keys we won't ever have (and their titleID need to match the host game too).
I think you missed the part where the cia is running from a hacked 3ds and is being transmitted to a nonhacked 3ds with download play.
 
The client needs to have signpatch because it temp. installs the CIA, what's the point then?
 
It doesn't "temp install the CIA" it simply copies what it needs to memory and runs from there, it assumes it's been verified by the other 3ds and runs the code with no check
If we were characters in a book, we'd be written on the same page.
 
  • Like
Reactions: Deleted User
Doesn't the CIA have to pass signature checks though? How would you pass restrictions on the client 3ds? I agree with @TuxSH that just sending over a CIA (that's just temporary) won't do anything by default.
 
Doesn't the CIA have to pass signature checks though? How would you pass restrictions on the client 3ds? I agree with @TuxSH that just sending over a CIA (that's just temporary) won't do anything by default.
It doesn't send the cia. It sends a chunk of unencrypted data that the 'client' loads directly into memory. It goes through NO further checks as the 'client' assumes its legit. If it doesn't require it to be signed you don't need a signiture patch. Jesus.
 
Maybe people should read 3dbrew. If we would be able to bypass all this as easy we would not be stuck on 9.2.

http://3dbrew.org/wiki/Download_Play#Broadcasted_application_data
All it does is send a legit CIA to the clients which verify it and install it if it is signed properly.
Tell me then how it's possible to send over modified Mario Kart tracks on an unexploitable 3ds as the client?

Also if you read I covered why downgrading is impossible
 
Tell me then how it's possible to send over modified Mario Kart tracks on an unexploitable 3ds as the client?
There's a difference between sending unsigned CIA's to unexploited clients and sending custom romfs. Also if you actually read the wiki link he posted, it does say that the format the CIA is sent in sends the romfs:
The CXI format is structured in the following order:
  • ...
  • and finally followed by an optional read-only filesystem (RomFS) - (Used for external file storage).
 
There's a difference between sending unsigned CIA's to unexploited clients and sending custom romfs. Also if you actually read the wiki link he posted, it does say that the format the CIA is sent in sends the romfs:
Modifying romFS, which is part of the CIA, would break the signature though...
 
There's a difference between sending unsigned CIA's to unexploited clients and sending custom romfs. Also if you actually read the wiki link he posted, it does say that the format the CIA is sent in sends the romfs:
So you can modify an unsigned cia with an exploit and send it over. Also there is no difference because the cia has to be unsigned to modify the romfs anyway.
 
Modifying romFS, which is part of the CIA, would break the signature though...
I don't think the romfs is included in the signature check, if it did, I don't think the concept of using hans as a romhack tool would work (I may be wrong, but quickly scouring the romfs article mentions nothing of checking the integrity of the romfs)
So you can modify an unsigned cia with an exploit and send it over. Also there is no difference because the cia has to be unsigned to modify the romfs anyway.
I explained a theory above, and just because the sender can pass the signature check doesn't mean the client can accept it.
 
I don't think the romfs is included in the signature check, if it did, I don't think the concept of using hans as a romhack tool would work (I may be wrong, but quickly scouring the romfs article mentions nothing of checking the integrity of the romfs)

I explained a theory above, and just because the sender can pass the signature check doesn't mean the client can accept it.
Your not proving the impossibility here. The romfs is inside the signed container file. Modifing it breaks that signiture. Yet we do, and the client accepts it. Now if this only works with unsigned cia's you still have the fact that the client accepts unsigned data within an encrypted packet. What is the huge difference between sending modified game scripts and a game script modified to have a security flaw that can be used to trigger an exploit? That's what I'm looking for.
 
Your not proving the impossibility here. The romfs is inside the signed container file. Modifing it breaks that signiture. Yet we do, and the client accepts it. Now if this only works with unsigned cia's you still have the fact that the client accepts unsigned data within an encrypted packet. What is the huge difference between sending modified game scripts and a game script modified to have a security flaw that can be used to trigger an exploit? That's what I'm looking for.
They don't store scripts (they don't even use scripts) in romfs though, it's generally used for game manuals and update data, not something like human-readable lua files. I'm going to stop here, if you want to do the research, and it ends up possible to actually send a exploitable CIA (that is able to start the ninjhax payload), that would be really cool. What i'm saying is that with the limited research I have done, chances are pretty slim.
 
I may be talking out of my ass, here, and I probably am, but - what if we were to exploit the stream of data sent *after* the executable rather than the executable itself? I would imagine that's handled differently, no? Sure, there are signature checks on the chunk of game code need to run the downloaded game. But, take Mario Kart for example - after the executable for the game is sent, there's a continuous stream of data sent after that. Racer positions, speeds, synchronization, etc. Could that be potentially tampered with?
 
  • Like
Reactions: Mrrraou
I may be talking out of my ass, here, and I probably am, but - what if we were to exploit the stream of data sent *after* the executable rather than the executable itself? I would imagine that's handled differently, no? Sure, there are signature checks on the chunk of game code need to run the downloaded game. But, take Mario Kart for example - after the executable for the game is sent, there's a continuous stream of data sent after that. Racer positions, speeds, synchronization, etc. Could that be potentially tampered with?
I think it's that. Otherwise, have fun sending 50~100MB of rom data at a rate of 200KB/s
Maybe people should read 3dbrew. If we would be able to bypass all this as easy we would not be stuck on 9.2.

http://3dbrew.org/wiki/Download_Play#Broadcasted_application_data
All it does is send a legit CIA to the clients which verify it and install it if it is signed properly.
 
  • Like
Reactions: Mrrraou

Site & Scene News

Popular threads in this forum