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

[mbcrazed]

I know this probably sounds ridiculous, but why don't you figure out how the 3DS functions 100%. Wouldn't that bring us one step closer to fingering it out? Study it inside and out, but I guess that's just my opinion!~

 

[Snailface]

I know this probably sounds ridiculous, but why don't you figure out how the 3DS functions 100%. Wouldn't that bring us one step closer to fingering it out? Study it inside and out, but I guess that's just my opinion!~

Sorry, couldn't resist.
http://p.bfram.es/captain-obvious-there-is-one-in-every-anime.jpg

 

[The Milkman]

Yeah, but that was newer the reason not to try. If nothing, it will be fun (that's why people play lottery)


ok, but how do we start doing that?

I thought people played the lottery to get large sums of money?

 

[Rydian]

What about the DS-3DS handling?

Does anyone know how the DS to 3DS mode works?

If the 3DS cartridges are different than the DS one, a modded card could bug the system.
(By modded card I mean like half DS half 3DS code)

We can dump 3DS and DS games(both encrypted), what happens if they're both in a card?

There are no hybrid games. The unit sends the cart some data, and gets a response in return. If the response matches a DS cart, it does some stuff. If the response matches a 3DS cart, it does other stuff.

If the response is mixed or matches neither, it doesn't do anything.

I know this probably sounds ridiculous, but why don't you figure out how the 3DS functions 100%. Wouldn't that bring us one step closer to fingering it out? Study it inside and out, but I guess that's just my opinion!~

That's what they're trying to do.

 

[mbcrazed]

Sorry, couldn't resist.
http://p.bfram.es/captain-obvious-there-is-one-in-every-anime.jpg

Haha! xD It's cool!~

 

[mbcrazed]

There are no hybrid games. The unit sends the cart some data, and gets a response in return. If the response matches a DS cart, it does some stuff. If the response matches a 3DS cart, it does other stuff.

If the response is mixed or matches neither, it doesn't do anything.

That's what they're trying to do.

I knew it sounded stupid! :/ I know there isn't an infinite supply of 3DS just to open up and screw with the MotherBoard, but it was just an opinion. A ridiculous one at that!

 

[doorbell8423]

Hi just wanted to tell you when you post something, try to put it in one post. Just use "edit" button.
http://gbatemp.net/help/terms

I thought people played the lottery to get large sums of money?

Yeah, those are expectations, to earn money, but it all depends on how you look on lottery..

 

[MrMarco]

Hi just wanted to tell you when you post something, try to put it in one post. Just use "edit" button.
http://gbatemp.net/help/terms


Yeah, those are expectations, to earn money, but it all depends on how you look on lottery..

Cool thing we'd be using our luck to try a 3DS key, not a large amount of money!

Now, does anyone know completely how the Wi-Fi updates are checked?
If it's made by the server, the 3DS, and if the 3DS will download it before checking(so then it would or not install).
If it downloads it, then checks if it's signed, we can make use of this in some way, right?

 

[Rydian]

If it downloads it, then checks if it's signed, we can make use of this in some way, right?

No, because it won't do anything with it if it's not signed.

Like, you can stick some porn on your SD card and put it in the 3DS, but it's not going to do anything with it.

 

[MrMarco]

No, because it won't do anything with it if it's not signed.

Like, you can stick some porn on your SD card and put it in the 3DS, but it's not going to do anything with it.

Now what does it use to check if the data is signed? Even that process might have a flaw that'll lead to the key... Or kernel acess, don't you think?

 

[Rydian]

Now what does it use to check if the data is signed? Even that process might have a flaw that'll lead to the key... Or kernel acess, don't you think?

That's what the people hacking the damn system are trying to figure out.

I mean that theory is about as broad as "hey maybe if we hack it and give it the hack, it'll be hacked!"

No fucking duh.

 

[Ritsuki]

I'm not. The issue with finding the private key is that in order to test the private key, you need to try encrypting something with what you think the private key is, and then decrypting it with the public key to see if it works.

But the public key isn't known yet. It exists, but still inside the 3DS, so in order to test a guess for a key, people would need to feed it to the 3DS and try to run it each time, which means that mass-guessing of 50,000 keys a second and numbers like that are impossible.

Compare this to the Wii and DSi, who have their common keys known already, and thus brute-force programs against them are possible (just not feasible). Hell, somebody actually did this for the DSi already (resulting in failure and nobody else caring to run the program after a few weeks of course).

It was the possible/feasible distinction I wanted to point (I was too short on time to express my tought completely) Anyway, didn't know that somebody was courageous (or crazy) enough to try to brute force the DSi private key

 

[MrMarco]

That's what the people hacking the damn system are trying to figure out.

I mean that theory is about as broad as "hey maybe if we hack it and give it the hack, it'll be hacked!"

No fucking duh.

Sorry for being so obvious, but with that I ask how can you mod the system in order to actually understand how it works?

What about the dev unit, what can it do?

As soon as we know how to observe the system at work, we can then try to understand it...

 

[SifJar]

Compare this to the Wii and DSi, who have their common keys known already, and thus brute-force programs against them are possible (just not feasible). Hell, somebody actually did this for the DSi already (resulting in failure and nobody else caring to run the program after a few weeks of course).

It was the common key people tried to bruteforce for the DSi, not the private key. I was never 100% clear on how a valid decryption was verified, but I guess it is a case of decrypting the signature (i.e. encrypted hashes) and checking these against the hashes of the content. If they match, common key has been found (but private key is still secure).

As soon as we know how to observe the system at work, we can then try to understand it...

http://www.flickr.com/photos/neimod/8298047673/in/photostream
http://www.flickr.com/photos/neimod/6487818901/in/photostream
http://www.flickr.com/photos/neimod/6487815875/in/photostream
http://www.flickr.com/photos/neimod/6487813587/in/photostream
http://www.flickr.com/photos/neimod/6487810819/in/photostream

neimod has been observing the system "at work" for a long time, and does understand a lot of stuff (see: 3dbrew.org).

 

[Rydian]

It was the common key people tried to bruteforce for the DSi, not the private key. I was never 100% clear on how a valid decryption was verified, but I guess it is a case of decrypting the signature (i.e. encrypted hashes) and checking these against the hashes of the content. If they match, common key has been found (but private key is still secure).

Was it? I thought the DSi common key was already found, while the brute forcing was a failure.

 

[MrMarco]

It was the common key people tried to bruteforce for the DSi, not the private key. I was never 100% clear on how a valid decryption was verified, but I guess it is a case of decrypting the signature (i.e. encrypted hashes) and checking these against the hashes of the content. If they match, common key has been found (but private key is still secure).




http://www.flickr.com/photos/neimod/8298047673/in/photostream
http://www.flickr.com/photos/neimod/6487818901/in/photostream
http://www.flickr.com/photos/neimod/6487815875/in/photostream
http://www.flickr.com/photos/neimod/6487813587/in/photostream
http://www.flickr.com/photos/neimod/6487810819/in/photostream

neimod has been observing the system "at work" for a long time, and does understand a lot of stuff (see: 3dbrew.org).

That's a start. I'll read the whole website to see what I learn...

 

[Syphurith]

There are Some information about the 3DS Common Key.

Spoiler

3DS common key Usage [from 3dbrew.org, please use search to see the whole text]

DownloadPlay:Broadcasted application data
The CXI application content is again encrypted, this time using 128-bit AES CBC. The encryption uses the decrypted titlekey of the ticket, and the titleid padded with zeros as the IV. To get the decrypted titlekey, the titlekey stored in the ticket must be decrypted using 128-bit AES-CBC with the 3DS common key, and the same IV as mentioned previously.
So in actuality, the 3DS application code, as it is being transmitted wirelessly has been encrypted 3 times:
The first time is using 128-bit AES CTR encryption for the ExeFS of the CXI format,
the second time is using 128-bit AES CBC encryption in the archive data,
and the third time is using 128-bit AES CTR for the WPA2 encryption.

CIA:Title Key Encryption
To encrypt an unencrypted title key, you need:
Common key (as byte array)
Title ID (as ulong)
(and of course the unencrypted title key you want to encrypt) (as byte array)
The title key encryption process starts by converting the ulong (Title ID) into a byte array using by retrieving the bytes of the Title ID using BitConverter.GetBytes(). If the converted bytes (title ID) are in Little Endian, reverse those bytes. (in C# it would be Array.Reverse(byte_array_from_bitconverter)) This process makes the Title Key encryption IV.
Next, after you've gotten your Title Key's IV, you can start your cryptography transformation. Using AESManaged, where:
Key = Common Key
IV = the byte array found in the conversion process above
Mode = CipherMode.CBC.
Create the encryptor (AesManaged.CreateEncryptor(key, iv)) where the key and IV are both the same as above.
Then, create a CryptoStream and a MemoryStream. The Crypto stream should start with the arguments (memorystream, aes_transform_from_above, CryptoStreamMode.Write).
Write to the CryptoStream where buffer=unencrypted_titlekey, offset=0, and count=the length of the unencrypted title key.
Use FlushFinalBlock() on the CryptoStream.
Finally, then, the encrypted title key will be available from your memory stream. (to output the calculated encrypted title key as a byte array, you can use memorystream.ToArray(), for example)

Title Data Structure:-
Unlike the TMD, a decrypted version of the NCCH files cannot be retrieved from Nintendo's CDN, the NCCH files do exist on Nintendo's CDN but are encrypted. Decrypting CDN versions of content, requires the title's ticket, and the common key specified by an index in the ticket. Of course editing/deleting ".app" files will have an effect. Deleting/renaming the manual ".app' will cause the manual not to load when clicked on. And deleting/renaming the executable ".app" will cause the application to not load, and the 3D Banner does not show(The banner is loaded each time from the game's executable NCCH when the home menu loads, it is not cached like the icon and name).

CommonETicket:Structure
The titlekey is decrypted by using the AES engine with the ticket common-key keyslot where the keyY is one of 6 keyYs loaded via the keyY index stored in the ticket. AES-CBC mode is used where the IV is the big-endian titleID. Note that on a retail unit index0 is a retail keyY, while on a dev-unit index0 is the dev common-key which is a normal-key.(On retail for these keyYs, the hardware key-scrambler is used)

In short, here are what the key is used on 3ds processes.
(just collected a moment ago. May be out-dated if Ninty use that key more commonly)
Encryption: DownloadPlay,
Decryption: DownloadPlay, CIA(& TitleDataStructure), CommonETicket
So here comes a guess.

Spoiler

Even there is no evidence of just finding it somewhere, we may interrupt the process called (well we may need a ramhaxx to replace those content we want to encrypt) to make it encrypted those what we want. Then, It will be easier to break it, since we can get many pairs of encrypted content with the decrypted one (Specified!). This would decease the cost (probably) of the brute-force. Well check the papers [1,2] please (if you are too interested in that). Even we can not interrupt the actual encryption (only replace those to be encrypted, if process is implemented in hardware) the more pairs we get, the more easily Math. Prof.s may find out.

Spoiler

Only one pair detected - thanks to 3dsguy - now. that is enough for brute-force but not good enough. >>LINK<<

But only interrupt the ENCRYPTION not the DECRYPTION. for DECRYPTION it can never generate such a pair (Well it may be not useful as ENCRYPTION).

In breif presentation: (For those who don't undestand)

Spoiler

(#1) Content(NOT CLEAR to us) ---->- Encryption ---->- Result(Encrypted)
(#2) ClearContent(Specified) ---->- Encryption ---->- Result(Encrypted,Specified)

Well just brute-force is never a good choice. (So you would have to exploit the AES-CBC.)
I highly suggested you take a part in Decapping, since we may find the key in hardware.

 

[KingBlank]

What if we capture a 3DS and force it to sign some 3DS software, then we just have to shove it into the 3DS on a SD card.

Although, that would only work for that 3DS...

We could mass produce 3DS 'hacking' kits that consist of a modified 3DS charger that shocks the 3DS every time it refuses to sign data, eventually we could train them to always sign stuff

 

[MrMarco]

What if we capture a 3DS and force it to sign some 3DS software, then we just have to shove it into the 3DS on a SD card.

Although, that would only work for that 3DS...

We could mass produce 3DS 'hacking' kits that consist of a modified 3DS charger that shocks the 3DS every time it refuses to sign data, eventually we could train them to always sign stuff

It might work! I'll try it!

 

[Rydian]

Come on guys, are you kidding? There's no way that will work.

Because the 3DS has no nipples to attach the electric shockers too.