Hacking Post your ideas regarding how to hack the 3DS, here

[Thesolcity]

I have an idea - we can just make a 3DS from scratch! Or we could just follow the last post's advice since this thread is nearly dead. When someone hacks the firmware or creates a mod chip, we'll see what happens. I'm thinking that Nintendo does additional checks now, even after a cart is loaded. The old trick on the DS of booting a legit game then swapping out the data in exploitable areas of the game's code won't work now? It makes sense that it works for DS mode because they emulate a DSi, it seems. For 3DS games, that won't work probably because of checking it randomly or on intervals/every load from ROM to RAM.

So far we haven't seen this additional checking mechanism in place yet. So far, all the evidence points to a sandboxed system and signature checks, but nothing other than that.
And yes, this thread is dead. (Well, it was never alive tbh, I just love shooting down theories that won't work)

CRC checks on the save file.
Is it unreasonable to assume each game is whitelisted as the DSi did AND contains a CRC check? Also have we figured out why the 3DS takes so long to boot? Maybe there's a check in there.

 

[Seaking]

why facepalm he found a glitch and is curious if it can be exploitable

Care to state your legitimate reason to facepalm at him, sir?

It's not exploitable.
This is a dev 3ds with an installed application which was made by someone has the sdk, so it's uninteresting.
Read this: http://www.3dbrew.org/wiki/CIA

umm...what?
the picture i posted was from a retail Mario Kart 7 cartridge, and a retail 3DS system...so, i dont know how you thought i was using a dev 3DS

Do you know how you did it?

i actually have no clue, besides i was downloading 10 things from the eshop, and they were on pause, and i was racing online on mk7

 

[wchill]

I have an idea - we can just make a 3DS from scratch! Or we could just follow the last post's advice since this thread is nearly dead. When someone hacks the firmware or creates a mod chip, we'll see what happens. I'm thinking that Nintendo does additional checks now, even after a cart is loaded. The old trick on the DS of booting a legit game then swapping out the data in exploitable areas of the game's code won't work now? It makes sense that it works for DS mode because they emulate a DSi, it seems. For 3DS games, that won't work probably because of checking it randomly or on intervals/every load from ROM to RAM.

So far we haven't seen this additional checking mechanism in place yet. So far, all the evidence points to a sandboxed system and signature checks, but nothing other than that.
And yes, this thread is dead. (Well, it was never alive tbh, I just love shooting down theories that won't work)

CRC checks on the save file.
Is it unreasonable to assume each game is whitelisted as the DSi did AND contains a CRC check? Also have we figured out why the 3DS takes so long to boot? Maybe there's a check in there.

CRC checks on the save file are not examples of random checks on the game ROM (and are easily circumvented by not touching the save file)
And not every game is whitelisted: every DS game released after the DSi has a checksum in its header for the DSi to verify (or something like that).

The reason behind the 3DS booting time is not certain, but it can very well be due to the hypervisor and the initial checks the 3DS must do. This does not necessarily mean that there are more checks.

Of course, there remains the possibility of random checks, which is possible according to my hypervisor theory. There's no evidence of it, but the possibility remains. (Again, CRC checks do not count as it would most likely only be during save read/write commands, most likely to lock out save game exploits. Wrong way to approach this problem anyway, especially with modified saves not even being able to be copied since DSi 1.4.3)

 

[alphamule]

I have an idea - we can just make a 3DS from scratch! Or we could just follow the last post's advice since this thread is nearly dead. When someone hacks the firmware or creates a mod chip, we'll see what happens. I'm thinking that Nintendo does additional checks now, even after a cart is loaded. The old trick on the DS of booting a legit game then swapping out the data in exploitable areas of the game's code won't work now? It makes sense that it works for DS mode because they emulate a DSi, it seems. For 3DS games, that won't work probably because of checking it randomly or on intervals/every load from ROM to RAM.

So far we haven't seen this additional checking mechanism in place yet. So far, all the evidence points to a sandboxed system and signature checks, but nothing other than that.
And yes, this thread is dead. (Well, it was never alive tbh, I just love shooting down theories that won't work)

Checksum checks on the save file.
Is it unreasonable to assume each game is whitelisted as the DSi did AND contains a Checksum check? Also have we figured out why the 3DS takes so long to boot? Maybe there's a check in there.

Checksum checks on the save file are not examples of random checks on the game ROM (and are easily circumvented by not touching the save file)
And not every game is whitelisted: every DS game released after the DSi has a checksum in its header for the DSi to verify (or something like that).

The reason behind the 3DS booting time is not certain, but it can very well be due to the hypervisor and the initial checks the 3DS must do. This does not necessarily mean that there are more checks.

Of course, there remains the possibility of random checks, which is possible according to my hypervisor theory. There's no evidence of it, but the possibility remains. (Again, Checksum checks do not count as it would most likely only be during save read/write commands, most likely to lock out save game exploits. Wrong way to approach this problem anyway, especially with modified saves not even being able to be copied since DSi 1.4.3)

Fixed it for ya.
I could break even the 32-bit version of xor CRC with a calculator... Same with additive. A checksum based on a combination of a signature and TPM to do the signing would be a lot harder to hack but might have the same issues as HDCP and SSL... Good ideas with flawed implementations. HDCP was beat using linear algebra and 40-odd keys based on a shared secret. SSL suffers from hacking it once and then all keys based on that certificate have to be revoked.

It seems obvious that it's probably going to take a crypto implementation weakness or hardware exploit at this point, but who knows... There might be some other way found that they (experts) aren't mentioning until tested and then only spoonfed. Kind of like the exploits that weren't disclosed/used/released until after Nintendo's November patches.

 

[wchill]

I have an idea - we can just make a 3DS from scratch! Or we could just follow the last post's advice since this thread is nearly dead. When someone hacks the firmware or creates a mod chip, we'll see what happens. I'm thinking that Nintendo does additional checks now, even after a cart is loaded. The old trick on the DS of booting a legit game then swapping out the data in exploitable areas of the game's code won't work now? It makes sense that it works for DS mode because they emulate a DSi, it seems. For 3DS games, that won't work probably because of checking it randomly or on intervals/every load from ROM to RAM.

So far we haven't seen this additional checking mechanism in place yet. So far, all the evidence points to a sandboxed system and signature checks, but nothing other than that.
And yes, this thread is dead. (Well, it was never alive tbh, I just love shooting down theories that won't work)

Checksum checks on the save file.
Is it unreasonable to assume each game is whitelisted as the DSi did AND contains a Checksum check? Also have we figured out why the 3DS takes so long to boot? Maybe there's a check in there.

Checksum checks on the save file are not examples of random checks on the game ROM (and are easily circumvented by not touching the save file)
And not every game is whitelisted: every DS game released after the DSi has a checksum in its header for the DSi to verify (or something like that).

The reason behind the 3DS booting time is not certain, but it can very well be due to the hypervisor and the initial checks the 3DS must do. This does not necessarily mean that there are more checks.

Of course, there remains the possibility of random checks, which is possible according to my hypervisor theory. There's no evidence of it, but the possibility remains. (Again, Checksum checks do not count as it would most likely only be during save read/write commands, most likely to lock out save game exploits. Wrong way to approach this problem anyway, especially with modified saves not even being able to be copied since DSi 1.4.3)

Fixed it for ya.
I could break even the 32-bit version of xor CRC with a calculator... Same with additive. A checksum based on a combination of a signature and TPM to do the signing would be a lot harder to hack but might have the same issues as HDCP and SSL... Good ideas with flawed implementations. HDCP was beat using linear algebra and 40-odd keys based on a shared secret. SSL suffers from hacking it once and then all keys based on that certificate have to be revoked.

It seems obvious that it's probably going to take a crypto implementation weakness or hardware exploit at this point, but who knows... There might be some other way found that they (experts) aren't mentioning until tested and then only spoonfed. Kind of like the exploits that weren't disclosed/used/released until after Nintendo's November patches.

Yeah, got confused there for a bit. I can break it with paper and pencil.
Anyway, I have to ask what the goal of the people in this thread is. Homebrew or piracy?
Because honestly, at this stage, I can't see a possible path to homebrew, but I can see one to piracy (since 3DS games are not unsigned code...)

 

[Thesolcity]

I have an idea - we can just make a 3DS from scratch! Or we could just follow the last post's advice since this thread is nearly dead. When someone hacks the firmware or creates a mod chip, we'll see what happens. I'm thinking that Nintendo does additional checks now, even after a cart is loaded. The old trick on the DS of booting a legit game then swapping out the data in exploitable areas of the game's code won't work now? It makes sense that it works for DS mode because they emulate a DSi, it seems. For 3DS games, that won't work probably because of checking it randomly or on intervals/every load from ROM to RAM.

So far we haven't seen this additional checking mechanism in place yet. So far, all the evidence points to a sandboxed system and signature checks, but nothing other than that.
And yes, this thread is dead. (Well, it was never alive tbh, I just love shooting down theories that won't work)

CRC checks on the save file.
Is it unreasonable to assume each game is whitelisted as the DSi did AND contains a CRC check? Also have we figured out why the 3DS takes so long to boot? Maybe there's a check in there.

CRC checks on the save file are not examples of random checks on the game ROM (and are easily circumvented by not touching the save file)
And not every game is whitelisted: every DS game released after the DSi has a checksum in its header for the DSi to verify (or something like that).

The reason behind the 3DS booting time is not certain, but it can very well be due to the hypervisor and the initial checks the 3DS must do. This does not necessarily mean that there are more checks.

Of course, there remains the possibility of random checks, which is possible according to my hypervisor theory. There's no evidence of it, but the possibility remains. (Again, CRC checks do not count as it would most likely only be during save read/write commands, most likely to lock out save game exploits. Wrong way to approach this problem anyway, especially with modified saves not even being able to be copied since DSi 1.4.3)

After thinking about it, CRC checks do no good since you can forge them anyway.

 

[el_venga]

my theory on why we are not seeing real results could be devs waiting for the rumored 3ds lite. if it turns out to be true and nintendo uses same hardware, a hardware based exploit can still be used there. if the so called hardware exploit is released and then nintendo cant patch it they just have to change a few things on hardware to make it useless.

 

[SuzieJoeBob]

Would it be possible to compare cross-platform games??? Lego Star Wars was made for 3DS and DS, so just about all of the DS game's code would be in the 3DS version, and the only other pieces that were added are the 3-D implementations and the streetpass (if it has it).

 

[wchill]

3DS Lite hasn't even been formally announced, that theory is absurd.
Also, comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

 

[alphamule]

3DS games are not unsigned code...)

Yeah, shows the real reasons behind all the security. Kill off a generation of hardware's homebrew, and the generation after it will have less people capable of hacking it for casual piracy. Makes a weird sort of sense! It also forces people to go to Nintendo and it's licensees for software = more franchise fees for Nintendo. :/

They don't just do byte-level patches to get 3DS support or turn off 3DS features on the DS. It's going to be totally recompiled after all the development work, among other things. It is however, a partially known plaintext because huge portions of code will stay the same. Kind of pointless though because it's still unfeasible. 10^30 might be less than 10^40 or 10^60 but it's still way too much. Made-up number of possibilities but it's not too far from the truth.

 

[el_venga]

3DS Lite hasn't even been formally announced, that theory is absurd.
Also, comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

thats why i said rumored. it is not absurd because iPhone hackers do that in some situations to avoid apple fix some exploits. please read entire post before you post your opinion.

 

[wchill]

3DS Lite hasn't even been formally announced, that theory is absurd.
Also, comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

thats why i said rumored. it is not absurd because iPhone hackers do that in some situations to avoid apple fix some exploits. please read entire post before you post your opinion.

I am quite aware of the iOS scene. I have also read the entire post.
What you are failing to realize is that the 3DS was released not even a year ago. Even if a 3DS Lite is rumored, most likely it will not be produced until at least a year after it is announced. For the iPhone, it's fairly obvious when new hardware revisions come out because Apple releases on a yearly cycle.
In addition, announcing/releasing the 3DS Lite now will only mean a ton of backlash from those users who have already bought a 3DS. If you look at console revisions, generally they come at least two years after the original (excluding the DSi XL, which was not a "Lite" revision).

If an exploit is currently in the works, it would most likely be released before the 3DS Lite (unless the 3DS Lite had just been announced/released; in that case then the exploit would be saved). The reason is that there really is no point waiting two years for a POSSIBLE revision and risk having Nintendo patch it beforehand, possibly (look at what happened to SHAtter).

Please consider all sides of an argument/point before bashing a post.

 

[McHaggis]

[...] comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

You wouldn't be changing the low level code to make an exploit, though. If anything, you'd be modifying a game's save data (though it's not currently possible) to create a buffer overflow. Although the SDK is different, it's still down to the developer to check the lengths of strings. I'm hardly an expert on the subject, but I'm pretty sure I have the basics right.

It is possible the save format could be different, though. In fact, the save format WILL be different because the structure of 3DS saves is different to DS saves. However, it's possible that the save structure could be very similar in parts because the underlying code would not change much (an example I can think of is Secret of Mana for the iPhone, most of the offsets relative to other parts of the save were the same as the SNES version). It's not entirely unthinkable for an exploit to exist in both games if the bare minimum is done during porting.

 

[wchill]

[...] comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

You wouldn't be changing the low level code to make an exploit, though. If anything, you'd be modifying a game's save data (though it's not currently possible) to create a buffer overflow. Although the SDK is different, it's still down to the developer to check the lengths of strings. I'm hardly an expert on the subject, but I'm pretty sure I have the basics right.

It is possible the save format could be different, though. In fact, the save format WILL be different because the structure of 3DS saves is different to DS saves. However, it's possible that the save structure could be very similar in parts because the underlying code would not change much (an example I can think of is Secret of Mana for the iPhone, most of the offsets relative to other parts of the save were the same as the SNES version). It's not entirely unthinkable for an exploit to exist in both games if the bare minimum is done during porting.

I was not discussing comparing save formats, just whether the programming itself could be compared.
Also, save game exploits will not work, as we have mentioned many times before; the 3DS does checks on saves to ensure they have not been tampered with. There is no doubt that a simple port will have a very similar save structure (this will vary per game, of course). However, it is irrelevant as we have no way of running said exploit if we were to make one.

 

[McHaggis]

I was not discussing comparing save formats, just whether the programming itself could be compared.
Also, save game exploits will not work, as we have mentioned many times before; the 3DS does checks on saves to ensure they have not been tampered with. There is no doubt that a simple port will have a very similar save structure (this will vary per game, of course). However, it is irrelevant as we have no way of running said exploit if we were to make one.

There's no need to be so defensive. SuzieJoeBob brought up the idea of comparing cross-platform games which, in my mind, is someone less technically minded suggesting that if we can find an exploit in a game on a console that's already hacked we might be able to exploit the same vulnerability on the 3DS. You shot that suggestion down saying that the SDKs were different so that wouldn't be possible, and that's why I said what I said. Regardless of what you are or aren't discussing, I said what I said in response because I thought it was relevant.

I also said editing saves wasn't currently possible, as you kindly elaborated for me. However, that doesn't mean it won't ever be possible; all the checksums and hashes are in the save file, so the algorithms could possibly be reversed. That being said, I don't think a save game hack will be the first exploit for the 3DS. I think it's more likely that a hardware hack will lead to a software hack (like on the Wii).

 

[wchill]

I was not discussing comparing save formats, just whether the programming itself could be compared.
Also, save game exploits will not work, as we have mentioned many times before; the 3DS does checks on saves to ensure they have not been tampered with. There is no doubt that a simple port will have a very similar save structure (this will vary per game, of course). However, it is irrelevant as we have no way of running said exploit if we were to make one.

There's no need to be so defensive. SuzieJoeBob brought up the idea of comparing cross-platform games which, in my mind, is someone less technically minded suggesting that if we can find an exploit in a game on a console that's already hacked we might be able to exploit the same vulnerability on the 3DS. You shot that suggestion down saying that the SDKs were different so that wouldn't be possible, and that's why I said what I said. Regardless of what you are or aren't discussing, I said what I said in response because I thought it was relevant.

I also said editing saves wasn't currently possible, as you kindly elaborated for me. However, that doesn't mean it won't ever be possible; all the checksums and hashes are in the save file, so the algorithms could possibly be reversed. That being said, I don't think a save game hack will be the first exploit for the 3DS. I think it's more likely that a hardware hack will lead to a software hack (like on the Wii).

I apologize if I sounded defensive. I should be studying for some tests and I'm not really in a good mood right now.
Also, permanent save game exploits will most likely not happen until we get some CFW going. You are correct on the hardware hack probably being the first thing to happen.
I would also like to point out that checksums/hashes are designed to be irreversible. We can't simply "reverse" an algorithm, as there is not enough information to reconstruct data from a hash. If you're talking about reverse-engineering the algorithm, it appears that it's also based on a stream cipher, which makes this relatively easy to break if we have access to the 3DS's pseudo-random number generator and the initial seed used with the stream cipher.
Anyway, because we do not, it's not practical for the time being. Unfortunately, it also looks like Nintendo is able to change the type of save encryption used, according to 3DBrew (the scheme changed at firmware 2.0.0-4). Meaning that being able to encrypt our own saves will only work until the next firmware update.

 

[McHaggis]

I apologize if I sounded defensive. I should be studying for some tests and I'm not really in a good mood right now.
Also, permanent save game exploits will most likely not happen until we get some CFW going. You are correct on the hardware hack probably being the first thing to happen.
I would also like to point out that checksums/hashes are designed to be irreversible. We can't simply "reverse" an algorithm, as there is not enough information to reconstruct data from a hash. If you're talking about reverse-engineering the algorithm, it appears that it's also based on a stream cipher, which makes this relatively easy to break if we have access to the 3DS's pseudo-random number generator and the initial seed used with the stream cipher.
Anyway, because we do not, it's not practical for the time being. Unfortunately, it also looks like Nintendo is able to change the type of save encryption used, according to 3DBrew (the scheme changed at firmware 2.0.0-4). Meaning that being able to encrypt our own saves will only work until the next firmware update.

No worries, good luck with your tests

I was referring mostly to older games, for which the encryption method was already broken. "Reversed" was a poor choice of words, but I was referring to figuring out the data the hashes are calculated from. If they're not using a salt common to all 3DS consoles, though, all the data that goes into the calculated hash is right there in the save file, which would make it a matter of knowing the hashing method and the offsets of the data being hashed. You're absolutely right that this isn't at all easy, otherwise it would probably already have been done.

There are a lot of games out that still use the old encryption method, which indicates that games need to be compiled with a newer version of the SDK in order to take advantage of the newer encryption. If old games had their saves re-encrypted with the 2.0.0-4+ method, those saves would appear to be corrupted on 3DS consoles with older firmwares. That's not to say that Nintendo can't fix any save game exploits in the future, though. They could release a firmware that checks saved games when the cart is inserted, removing any saves that may exploit a vulnerability by verifying the offsets and lengths of null-terminated strings.

In any case, Nintendo appears to have learned a lot about security over the last 10 years. I don't think any of the hacking theories here are particularly useful, but of course this thread isn't about posting hacking theories that will actually work

 

[alphamule]

If you're talking about reverse-engineering the algorithm, it appears that it's also based on a stream cipher, which makes this relatively easy to break if we have access to the 3DS's pseudo-random number generator and the initial seed used with the stream cipher.

Which unfortunately seems to take a physical hack on an impractical level.

 

[Luigi2012SM64DS]

my brain hurts

 

[el_venga]

3DS Lite hasn't even been formally announced, that theory is absurd.
Also, comparing code cross-platform won't work because the SDKs used for the DS and 3DS are different, so a lot of the low-level code will be different.

thats why i said rumored. it is not absurd because iPhone hackers do that in some situations to avoid apple fix some exploits. please read entire post before you post your opinion.

I am quite aware of the iOS scene. I have also read the entire post.
What you are failing to realize is that the 3DS was released not even a year ago. Even if a 3DS Lite is rumored, most likely it will not be produced until at least a year after it is announced. For the iPhone, it's fairly obvious when new hardware revisions come out because Apple releases on a yearly cycle.
In addition, announcing/releasing the 3DS Lite now will only mean a ton of backlash from those users who have already bought a 3DS. If you look at console revisions, generally they come at least two years after the original (excluding the DSi XL, which was not a "Lite" revision).

If an exploit is currently in the works, it would most likely be released before the 3DS Lite (unless the 3DS Lite had just been announced/released; in that case then the exploit would be saved). The reason is that there really is no point waiting two years for a POSSIBLE revision and risk having Nintendo patch it beforehand, possibly (look at what happened to SHAtter).

Please consider all sides of an argument/point before bashing a post.

3ds will be 1 year in a few weeks of released in japan and besides selling pretty damn well still has a couple of issues, like battery life, so nintendo is certainly working on a revision being lite or not, at least being announced on E3 or before. you have a point too but lets agree on disagree because we are off topic XD.